Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000011_owner-urn-ietf _Tue Oct 8 09:45:37 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA02389 for urn-ietf-out; Tue, 8 Oct 1996 09:45:37 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA02377 for <[e-mail]>; Tue, 8 Oct 1996 09:45:03 -0400
Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA15112  (mail destined for [e-mail]); Tue, 8 Oct 96 09:45:01 -0400
Received: from [206.155.199.11] by smtp1.abraxis.com (NTMail 3.01.03) id za051713; Tue, 8 Oct 1996 09:48:49 -0400
Message-Id: <[e-mail]>
Date: Tue, 08 Oct 1996 09:50:04 -0400
From: Michael Mealling <[e-mail]>
Organization: Network Solutions
X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc)
Mime-Version: 1.0
To: Larry Masinter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [URN] advantages of NAPTR over PURLs
References: <96Oct7.191009pdt."2771"@golden.parc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Michael Mealling <[e-mail]>
Errors-To: [e-mail]

Larry Masinter wrote:
> Re replication:
>
> > We can provide multiple A records for www.purl.org, but there is no
> > way to do smart prioritization between the more and less capable
> > hosts.
>
> Why is this easier to do with NAPTR records than A records? Could we
> extend A records for HTTP servers so that you could do smart
> prioritization? ("If this is such a great idea, why save it for
> URNS").

The only way to do this is with a new record. That record is the
SRV record which a lot of people are planning on using. A records
only have the IP address, nothing else.


> > Depending on how the multiple A records are provided, there may also
> > be an obscure error that truncates the list of responses. The NAPTR
> > proposal will not suffer that error.
>
> Is this a bug in the implementation of DNS? If the bug is there for A
> records, why wouldn't it be there for NAPTR records? Is this a design
> error that could be fixed?

No. It has to do with the allowable packets size for DNS via UDP.
If it goes over then the packet is truncated causing the client
to have to reconnect via TCP. IF the part that is truncated
though is in the additional information field then the user
is NOT given an error. This is a problem with DNS that
cannot be fixed. Even if you consider it a problem....


> > The real point of the NAPTR proposal is that it gives us a way to cope
> > with names, such as www.purl.org, that should be long-lived but aren't.
>
> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name. If you can't do
> that with ".org", then pick a new top level domain.

Because it has "purl.org" in it which is OWNED by OCLC. They pay the
bill. As far as the NIC is concerned they can do with it whatever
they want and we can't do squat about it. NAPTR should eventually
be a TLD all its own that is not 'owned' by anyone but the IANA (which
has its own problems but I won't go into that).



> >>Well, www.purl.org can migrate, too, can't it?
> > I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto
> > a machine that cannot be identified by the domain name that was used
> > for the earlier resolver, and terminating service on the original machine,
> > even if that machine remains up and running for other purposes.
> > So, no, www.purl.org cannot migrate according to my definition. (Better
> > terminology welcomed).
>
> If you want to be able to migrate PURL resolvers to other machines,
> you just assign a new IP address to the PURL resolver name. This is
> completely flexible. Don't use that DNS name for anything other than
> PURL resolution service. E.g., call it <scheme>.resolver.purl.org
> instead of just www.purl.org.
>
> The DNS entries for resolver.purl.org already give you all the
> indirection you need. Why add more?

Because we don't to be tied to DNS. The URN framework (not NAPTR)
works in all situations no matter if you have DNS or not. You
can run the service in an OSI world using X.500 (everyone scream).


> >>> and the resolution process allows multiple protocols
> >>The URL in the 'Location:' header of purl.org's response need not be
> >>'http:'.
>
> >We are not talking about the same thing. One could assign PURLs such as
> >   ftp://purl.foo.com/whatever
> >but once that PURL is assigned, we have to use FTP to resolve it. Since
> >the NAPTR draft doesn't require the resolution protocol to be embedded in
> >the identifier, we are free to offer multiple resolution protocols and to
> >change them over time. This is an important point, since over time we
> >will have increasingly efficient protocols.
>
> In the "PURL" method, the "resolution" is accomplished by using HTTP
> to talk to the resolution service and (if what you do is a GET)
> getting back a "303" response with a Location: header to do the
> URN->URL mapping.

This doesn't give you several things:
1) Areas of Authority. purl.org is authoritative for everything. I doubt
   if that scales. If its not authoritative how do I find the
authoritative
   server?

2) Services. I don't want just the URL. I want a URC. But I want it in
   SGML and not MARC. How can I get that out of a PURL?

3) Other available protocols. The PURL doesn't tell me what other
   protocols are available and which one it considers the best.

4) Equivalence. How do I match equivalence? Do I just match on
   the part after the hostname? If so then authority areas cannot
   exist. If not then your protocol is indistinquishable from the
   rest of the authority area.

There is not ONE killer reason why the URN framework is better than
PURLs. There are alot of smaller ones....

-MM
--
------------------------------------------------------------------------------
Michael Mealling    | 505 Huntmar Park Drive       | Phone:  [phone]
Software Engineer    | Herndon, VA 22070           | Fax:    [phone]
Network Solutions    | <URL:http://www.netsol.com>  | [e-mail]